Input/output (I/O) binding with automatic international electromechanical commission (IEC) address generation in remote terminal unit (RTU) configuration

ABSTRACT

A method includes automatically assigning, by at least one processor, an IEC address to an I/O binding variable for an RTU. This includes identifying a type of the I/O binding variable and identifying a size of the I/O binding variable based on the identified type. The size represents a number of memory locations to be used to store the I/O binding variable in at least one memory of the RTU. This also includes, in response to determining that the at least one memory contains a free space to store the I/O binding variable based on the identified size, assigning the IEC address identifying the free space to the I/O binding variable.

TECHNICAL FIELD

This disclosure is generally directed to industrial process control andautomation systems. More specifically, this disclosure is directed toinput/output (I/O) binding with automatic InternationalElectromechanical Commission (IEC) address generation in a remoteterminal unit (RTU) configuration.

BACKGROUND

A remote terminal unit (RTU) represents a device or system that provideslocalized control and data access at a site that is remote from asupervisory control and data acquisition (SCADA) system or otherautomation system. For example, multiple RTUs can be used at differentsites and for different purposes in an oil and gas field. The RTUs cancollect data, perform local control, record historical values usingsensors and actuators at different sites (such as wells, pipelines, andcompression stations), and provide live and historical data to anautomation system. The automation system can execute control logic andalter the operations of actuators at the different sites via the RTUs.The RTUs themselves could also incorporate algorithms for dataanalytics. RTUs have increased in usage and complexity from their earlydesigns in the 1970 s. Today, RTUs often need to reliably support alarge set of application-specific network capabilities and protocols, aswell as support a number of control execution models and provide smartdevice integration.

SUMMARY

This disclosure provides input/output (I/O) binding with automaticInternational Electromechanical Commission (IEC) address generation in aremote terminal unit (RTU) configuration.

In a first example, a method includes automatically assigning, by atleast one processor, an IEC address to an I/O binding variable for anRTU. This includes identifying a type of the I/O binding variable andidentifying a size of the I/O binding variable based on the identifiedtype. The size represents a number of memory locations to be used tostore the I/O binding variable in at least one memory of the RTU, andthe size represents a number of bytes. This also includes, in responseto determining that the at least one memory contains a free space tostore the I/O binding variable based on the identified size, assigningthe IEC address identifying the free space to the I/O binding variable.

In a second example, at least one processor configured to automaticallyassign an IEC address to an I/O binding variable for an RTU. The atleast one processor is configured to identify a type of the I/O bindingvariable and identify a size of the I/O binding variable based on theidentified type. The size represents a number of memory locations to beused to store the I/O binding variable in at least one memory of theRTU, and the size represents number of bytes. The at least one processoris also configured, in response to determining that the at least onememory contains a free space to store the I/O binding variable based onthe identified size, to assign the IEC address identifying the freespace to the I/O binding variable.

In a third example, a non-transitory computer readable medium embodiescomputer readable program code that, when executed by at least oneprocessor, causes the at least one processor to automatically assign anIEC address to an I/O binding variable for an RTU. This includesidentifying a type of the I/O binding variable and identifying a size ofthe I/O binding variable based on the identified type. The sizerepresents a number of memory locations to be used to store the I/Obinding variable in at least one memory of the RTU, and the sizerepresents a number of bytes. This also includes, in response todetermining that the at least one memory contains a free space to storethe I/O binding variable based on the identified size, assigning the IECaddress identifying the free space to the I/O binding variable.

Other technical features may be readily apparent to one skilled in theart from the following figures, descriptions, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure and its features,reference is now made to the following description, taken in conjunctionwith the accompanying drawings, in which:

FIG. 1 illustrates an example industrial process control and automationsystem having a remote terminal unit (RTU) according to this disclosure;

FIG. 2 illustrates an example device supporting input/output (I/O)binding with automatic International Electromechanical Commission (IEC)address generation in an RTU configuration according to this disclosure;

FIGS. 3A-1 and 3A-2 (together referred to herein as FIG. 3A) and FIGS.3B-1 and 3B-2 (together referred to herein as FIG. 3B) illustrateexample display screens of an IEC programming workspace including an IECaddress automatically assigned to each I/O binding variable according tothis disclosure;

FIG. 4 illustrates example memory blocks for I/O binding variablesaccording to this disclosure; and

FIG. 5 illustrates an example process of I/O binding with automatic IECaddress generation in an RTU configuration according to this disclosure.

DETAILED DESCRIPTION

FIGS. 1 through 5, discussed below, and the various examples used todescribe the principles of the present invention in this patent documentare by way of illustration only and should not be construed in any wayto limit the scope of the invention. Those skilled in the art willunderstand that the principles of the present invention may beimplemented in any suitable manner and in any type of suitably arrangeddevice or system.

FIG. 1 illustrates an example industrial process control and automationsystem 100 having a remote terminal unit (RTU) 102 according to thisdisclosure. Note that the RTU 102 may also be referred to in the art asa remote telemetry unit. Also note that while a single RTU 102 is shownhere, the system 100 could include any number of RTUs 102 distributed inone or more geographical areas.

The RTU 102 represents a device or system that provides localizedcontrol and data access at a site that is remote from a supervisorycontrol and data acquisition (SCADA) system or other control system 104.For example, the RTU 102 could be positioned at or near an oil, gas, orwater well or power substation. In these or other situations, the RTU102 can be used to collect data from local sensors and process the datato generate control signals for local actuators. The RTU 102 can alsointeract with the control system 104 as needed. In this way, processcontrol and automation functions can be provided at locations remotefrom the control system 104. The control system 104 is shown ascommunicating with the RTU 102 over a wired network 105 and usingwireless connections, such as via microwave, cellular, or other radiofrequency (RF) communications. However, the RTU 102 could communicatewith the control system 104 over any suitable wired or wirelessconnection(s). In some embodiments, the components 102-104 couldordinarily communicate using a wired connection, with wirelesscommunications used as backup.

The RTU 102 also communicates and interacts with one or more industrialfield devices 106. The field devices 106 could include sensors thatmeasure one or more characteristics of a process, actuators that alterone or more characteristics of a process, or other industrial fielddevices. In this example, the RTU 102 uses wired connections 108 tocommunicate with the field devices 106. The wired connections 108 couldinclude serial connections (such as RS232 or RS485 connections),Ethernet connections, industrial protocol connections, or other wiredconnections. Note, however, that the RTU 102 could also communicatewirelessly with one or more field devices 106.

The RTU 102 in this example also communicates and interacts with atleast one local user device 110. The user device 110 could be used bypersonnel to interact with the RTU 102 or with the field devices 106 orthe control system 104 communicating with the RTU 102. The user device110 includes any suitable structure supporting user interaction with anRTU.

Various other components could optionally be used with the RTU 102. Forexample, the RTU 102 could interact with one or more human-machineinterfaces (HMIs) 112, such as display screens or operator consoles. TheHMIs 112 can be used to receive data from or provide data to the RTU102. One or more security cameras 114 (such as Internet Protocolcameras) could be used to capture still or video images and to providethe images to a remote location (such as a security center) via the RTU102. A wireless radio 116 could be used to support wirelesscommunications between the RTU 102 and a remote access point 118, whichcommunicates with the control system 104 or other remote systems via thenetwork 105. The other remote systems can include a field device manager(FDM) 120 or other asset manager and/or an RTU builder machine 122. TheFDM 120 can be used to configure and manage assets such as field devices(including the field devices 106), and the RTU builder machine 122 canbe used to configure an RTU (including the RTU 102).

The RTU 102 has the ability to support a flexible mix of I/O channeltypes. For example, the channel types can include analog inputs (AIs),analog outputs (AOs), digital inputs (DIs), digital outputs (DOs), andpulse accumulator inputs (PIs). The AIs and AOs may or may not supportdigital communications, such as digital communications over 4-20 mAconnections compliant with the HIGHWAY ADDRESSABLE REMOTE TRANSDUCER(HART) protocol. Some RTUs 102 can achieve a desired mix of I/O channeltypes using I/O module that have a fixed number of inputs and outputs,where each input or output is fixed to a particular type. Other RTUs 102can achieve a desired mix of I/O channel types using I/O module withreconfigurable inputs or outputs. Moreover, some RTUs 102 can beexpandable so that one or more I/O modules (each with one or more I/Ochannels) can be used with the RTUs 102.

In some embodiments, the RTU builder machine 122 or other component cancommunicate with the RTU 102 in order to download the configuration andcontrol logic. The relationship between the IO variable and IEC addressis one part of the control logic. The compilation maps one or more I/Ovariables to one or more IEC addresses, which enables the RTU 102 todetermine a link between each I/O variable and an I/O channel through amutual link to the same IEC address. For example, firmware of the RTU102 may include a mapping of I/O channels to IEC addresses, which can beused in combination with a downloaded or otherwise received compilationof relationship information. As a particular example, by receiving thecompilation of relationship information, the RTU 102 can determine aparticular I/O variable that is bound to a particular I/O channelthrough a particular IEC address.

Prior to transmitting the compilation of relationship information to theRTU 102, the RTU builder machine 122 or other component can generate thecompilation of relationship information. In some embodiments, tofacilitate the generation of a compilation, a user executes RTUconfiguration software that supports the IEC61131-3 standard, like theRTU BUILDER software from HONEYWELL INTERNATIONAL INC. on the RTUbuilder machine 122. The RTU configuration software that supports theIEC61131-3 standard may include at least two workspaces, including anIEC programming workspace and an RTU configuration workspace.

Certain RTU configuration software that supports the IEC61131-3 standardrequires a user to manually assign an IEC address for each globalvariable. For an I/O binding variable, the user is required to assign anIEC address to the I/O binding variable after the I/O binding variableis bound to an I/O channel because the I/O binding variable belongs to aglobal variable. Due to human error, manual assignments of I/O bindingvariables to IEC addresses cause a series of problems. For example, theuser may assign the wrong IEC address to an I/O binding variable, or theuser may forget to assign an IEC address to an I/O binding variable. Asa result of such human error, the I/O binding variable cannot obtain acorrect I/O value. As another example, the process of manually assigningan IEC address includes not only typing an IEC address for each I/Obinding variable into a table but also counting a number of addressspaces that must be between a previously-assigned IEC address andanother IEC address assignment. The count of the number of addressspaces between two IEC address assignments depends on the type of I/Obinding variable of the previously assigned IEC address, and thedetermination of this count manually is subject to additional humanerror.

According to this disclosure, a tool 124 that facilitates automaticassignment of IEC addresses for I/O binding variables is provided in theRTU builder machine 122 or other component. By using the tool 124 forI/O binding with automatic IEC address generation in an RTUconfiguration, the process of configuring I/O bindings in an RTU iseasier, faster, and more accurate, and the risk of wrong operations isreduced. The tool 124 can use the IEC programming workspace within theRTU configuration software that supports the IEC61131-3 standard toautomatically assign an IEC address to each I/O binding variable. Moreparticularly, the tool 124 can determine the type of I/O bindingvariable and the size of the I/O binding variable, determine that atleast one memory includes a free space large enough to contain the I/Obinding variable, and assign an IEC address corresponding to the freespace to the I/O binding variable upon the determination. Examples ofI/O binding variable types include the following types: analog input,digital input, pulse input, analog output readback, digital outputreadback, analog output, and digital output. Each type of I/O bindingvariable can have a different size, such as when an analog input typehas a size of 24, the digital input type has a size of 28, the digitaloutput readback type has a size of 2, and the digital output type has asize of 1. Additional details regarding this functionality are providedbelow.

Although FIG. 1 illustrates one example of an industrial process controland automation system 100 having an RTU 102, various changes may be madeto FIG. 1. For example, the system 100 could include any number of eachcomponent. Also, the functional division shown in FIG. 1 is forillustration only. Various components in FIG. 1 could be combined,subdivided, or omitted and additional components could be addedaccording to particular needs. Further, while shown as beingincorporated into the RTU builder machine 122, the tool 124 could beused with other systems or devices. In addition, FIG. 1 illustrates oneexample operational environment where an RTU 102 can be used. One ormore RTUs could be used in any other suitable system.

FIG. 2 illustrates an example device 200 supporting I/O binding withautomatic IEC address generation in an RTU configuration according tothis disclosure. The device 200 could, for example, represent the RTU102. The device 200 could, for example, represent the RTU buildermachine 122 or other computing device supporting I/O binding withautomatic IEC address generation in an RTU configuration.

As shown in FIG. 2, the device 200 includes a bus system 205, whichsupports communication between at least one processor 210, at least onestorage device 215, at least one communications unit 220, and at leastone input/output (I/O) unit 225.

The processor 210 executes instructions that may be loaded into a memory230. The processor 210 may include any suitable number(s) and type(s) ofprocessors or other devices in any suitable arrangement. Example typesof processors 210 include microprocessors, microcontrollers, digitalsignal processors, field programmable gate arrays, application specificintegrated circuits, and discreet circuitry.

The memory 230 and a persistent storage 235 are examples of storagedevices 215, which represent any structure(s) capable of storing andfacilitating retrieval of information (such as data, program code,and/or other suitable information on a temporary or permanent basis).The memory 230 may represent a random access memory or any othersuitable volatile or non-volatile storage device(s). The persistentstorage 235 may contain one or more components or devices supportinglonger-term storage of data, such as a ready only memory, hard drive,Flash memory, or optical disc. The persistent storage 235 can bedisposed on the same integrated circuit chip as the processor 210, andis accordingly described as “on-chip memory.”

The communications unit 220 supports communications with other systemsor devices. For example, the communications unit 220 could include anetwork interface card or a wireless transceiver facilitatingcommunications over the network 105. The communications unit 220 maysupport communications through any suitable physical or wirelesscommunication link(s). More particularly, the communications unit 220could include a transmitter and a receiver for communicating withexternal devices.

The I/O unit 225 allows for input and output of data. For example, theI/O unit 225 may provide a connection for user input through a keyboard,mouse, keypad, touchscreen, or other suitable input device. The I/O unit225 may also send output to a display, printer, or other suitable outputdevice.

Although FIG. 2 illustrates one example of a device 200 supporting I/Obinding with automatic IEC address generation in an RTU configuration,various changes may be made to FIG. 2. For example, computing devicescome in a wide variety of configurations. The device 200 shown in FIG. 2is meant to illustrate one example type of computing device and does notlimit this disclosure to a particular type of computing device.

FIGS. 3A and 3B illustrate example display screens 300-301 of an IECprogramming workspace including an IEC address automatically assigned toeach I/O binding variable according to this disclosure. In someembodiments, the RTU builder machine 122 includes a display device thatdisplays the screens 300-301. In particular embodiments, the tool 124includes a suitable application for generating graphical displaysrepresenting the generation of a compilation of relationshipinformation.

As shown in FIG. 3A, the display screen 300 includes a table having oneor more expandable sections 305 a-305 d for various categories of data.For each expandable section 305 a-305 d, the table also includesmultiple rows 310 a-310 d and 315 a-315 b and multiple columns 320 a-320d. Each expandable section 305 a-305 d corresponds to a respective oneof the following categories: System Variables, Common Variables, InputI/O Variables (namely, input I/O binding variables), and Output I/OVariables (namely, output I/O binding variables). The columns include aName column 320 a containing a name 325 of each I/O binding variable, aType column 320 b containing a type 330 of each I/O binding variable, aUsage column 320 c that may contain an indicator 335 (VAR_GLOBAL) thatan I/O binding variable is used as a global variable, and an Addresscolumn 320 d containing an IEC address 340 automatically assigned to anI/O binding variable.

In response to a selection to add a new variable, the tool 124 adds arow to the table. The tool 124 can create an I/O binding variable inresponse to receiving a request with variable name to add a newvariable. The tool 124 can also enable a user to insert (such as bytyping or pasting text) a custom name into the Name column 320 a for avariable. As an example, a custom name of an input I/O binding typevariable could be “AI1” or “AI2” as shown in the display screen 300.Also, generic name of a digital output readback type variable could be“DO1_READBACK” or “DO2_READBACK”.

After the tool 124 adds a row to the table, the tool 124 prompts theuser to select a type of I/O binding variable in the Type column 320 b.For example, the tool 124 could cause the display screen 300 to show adrop-down list of various types of I/O binding variables according tothe category of the section 305 a-305 d. As a particular example, for anew variable added to the Input I/O Variables section 305 c, the tool124 may cause the display screen 300 to show a drop-down list includingtypes such as analog input, digital input, and digital output readback.As another particular example, for a new variable added to the OutputI/O Variables section 305 d, the tool 124 may cause the display screen300 to show a drop-down list including types such as analog output anddigital output. In a similar manner, in the usage column 320 c, theusage type can be selected for each row in the table.

In some embodiments, the user may not be required to input anyinformation to the Address column 320 d. Instead, the tool 124 canautomatically (without human intervention) assign an IEC address to eachI/O binding variable that does not have an IEC address. For example, thetool 124 can check the Address column 320 d for empty cells as anindicator of which row 310 a-310 d, 315 a-315 b has an I/O bindingvariable without an IEC address. In particular embodiments, in responseto receiving a selection to compile a project, the tool 124 canautomatically assign an IEC address to each I/O binding variable withoutan IEC address. The selection to compile a project can be a userselection to “make” or “rebuild” the project. Also, in particularembodiments, in response to determining the type of an I/O bondingvariable without an IEC address, the tool 124 can automatically generateand assign an IEC address to each I/O binding variable without an IECaddress.

IEC addresses have a standard syntax. For example, the IEC address canbegin with a percent sign (%) followed by a direction symbol, such as“I” for the input direction or “Q” for the output direction. Thedirection symbol is followed by a variable type symbol, such as “B”representing a data type. The last part of the IEC address can be theaddress number, such as “0” for a first address location within amemory, “1” for a second address location within a memory, and so on.

As shown in the display screen 301 of an IEC programming workspace ofFIG. 3B, the Input I/O Variables section 305 c can include differenttypes of I/O variables, each having its own size. Examples here includeANALOG_INPUT_TYPE variables named AI1 and AI2, which have a size of 24and are automatically assigned IEC addresses % IB0 and % IB24,respectively. The input I/O binding variable AI1 would occupy IECaddresses % IB0 through % IB23, and the input I/O binding variable AI2would occupy IEC addresses % IB24 through % IB47.

Although FIGS. 3A and 3B illustrate examples of display screens 300-301of an IEC programming workspace including an IEC address automaticallyassigned to each I/O binding variable, various changes may be made toFIGS. 3A and 3B. For example, the content and arrangement shown in eachfigure is for illustration only.

FIG. 4 illustrates example memory blocks 400-401 for I/O bindingvariables according to this disclosure. As an example, the memory blocks400-401 could denote memory locations in one or more of the storagedevices 215 of FIG. 2.

As shown in FIG. 4, the RTU 102 can include a first memory block 400 forstoring input I/O variables and a second memory block 401 for storingoutput I/O variables. Each memory block 400-401 includes multiple memorylocations 410 for storing information, and each memory location 410 canbe assigned individually or as part of a sub-block. Each memory location410 can store a byte of data. Any suitable number of memory locations410 could be used in each memory block 400-401, such as one hundredmemory locations. For simplicity, the memory blocks 400-401 will bedescribed as storing the I/O binding variables configured in the displayscreen 300-301 of the IEC programming workspace. It is understood thatthe memory blocks 400-401 can store additional types of information andother I/O variables.

For each I/O binding variable in the Input I/O Variables section 305 c,the tool 124 automatically reserves a sub-block of memory within thefirst memory block 400. Each sub-block can be identified by the firstIEC address in that sub-block. As an example, when the first memoryblock 400 is empty, a sub-block 415 identified by the IEC address % IB0of its first space can be assigned to the first I/O binding variable(AI1). The tool 124 accesses information indicating that theANALOG_INPUT_TYPE has a size of 28, so the tool 124 reserves thesub-block 415 that includes memory locations 410 from % IB0 to % IB27. Asub-block 420 identified by the IEC address % IB28 of its first spacecan be assigned to the second I/O binding variable (AI2). The tool 124accesses information indicating the size of the second I/O bindingvariable (AI2) based on its I/O binding variable type. As shown in thedisplay screen 300, the second I/O binding variable (AI2) has a variablesize of 2, so the sub-block 420 includes two memory locations 410 from %IB28 to % IB29. The tool 124 accesses information indicating the size ofthe third and fourth I/O binding variables (DO1_READBACK andDO2_READBACK) based on corresponding I/O binding variable types. Asshown in the display screen 300, the third I/O binding variable(DO1_READBACK) has a variable size of 2, so a sub-block 425 includes twomemory locations 410 from % IB30 to % IB31. In a similar manner, thetool 124 reserves the two memory locations 410 within a sub-block 430for the fourth I/O binding variable (DO2_READBACK) from % IB32 to %IB33. The tool 124 may consume the remainder of the memory locations 410in the first memory block 400 by reserving subsequently assignedsub-blocks 440 a-440 b for other input I/O binding variables.

In a similar manner, for each I/O binding variable in the Output I/OVariables section 305 d, the tool 124 automatically reserves a sub-blockof memory within the second memory block 401. As an example, when thesecond memory block 401 is empty except for information being stored atIEC address % QB0, a sub-block 445 identified by the IEC address % QB1can be assigned to the first I/O binding variable (DO1). The tool 124accesses information indicating that the DIGITAL_OUTPUT_TYPE has avariable size of 1, so the tool 124 reserves the sub-block 445 at amemory location 410 with an address of % QB1. The sub-block 450identified by an IEC address % QB2 of its first space can be assigned tothe second I/O binding variable (DO2). The tool 124 accesses informationindicating the size of the second I/O binding variable (DO2) based onits I/O binding variable type. As shown in the display screen 300, thesecond I/O binding variable (DO2) has a variable size of 1, so thesub-block 450 includes one memory location 410 at the address % QB2. Thetool 124 may consume the remainder of the spaces 410 in the secondmemory block 401 by reserving subsequently assigned sub-blocks for otheroutput I/O binding variables. Alternatively, the tool 124 may determinethat the remaining spaces in the second memory block 401 are free spaces455 that are empty or not assigned.

When an I/O binding variable is deleted, the sub-block previouslyreserved for that I/O binding variable is also deleted, so thecorresponding memory location(s) 410 become(s) free space. It may bedifficult for a user to look at the address column 320 d and manuallydetermine which memory locations 410 are free, especially when the freememory locations are located between other sub-blocks that are not free.However, the tool 124 can easily determine that an I/O binding variablehas been deleted and identify its memory location(s) for subsequentassignment. As a specific example, the tool 124 can determine that thesecond and third input I/O binding variables (AI2 and DO1_READBACK) havebeen deleted and determine that the memory locations 410 of thesub-blocks 420 and 425 are free or otherwise available to bere-assigned.

Later, when a new I/O binding variable is added, the tool can determinewhether the memory block(s) 400-401 have suitable free space, dependingon the type and size of the new I/O variable. If the size of the new I/Obinding variable is less than or equal to the number of free spaceshaving consecutive address numbers, the tool 124 can assign the firstIEC address of the free space to the new I/O binding variable. The tool124 can also reserve the corresponding sub-block having the necessarynumber of memory locations 410 for the new I/O variable.

Although FIG. 4 illustrates one example of memory blocks 400-401 for I/Obinding variables, various changes may be made to FIG. 4. For example,each of the memory blocks can include a different number of memorylocations 410 or can include IEC addresses ordered differently.

FIG. 5 illustrates an example process 500 of I/O binding with automaticIEC address generation in an RTU configuration according to thisdisclosure. In some embodiments, the process 500 can be implemented bythe processor(s) 210 within the device 200 of FIG. 2. As a particularexample, the process 500 can be implemented by the RTU builder machine122 using the tool 124, although the process 500 could be performed onany other suitable device.

In block 505, the tool 124 determines a name of an I/O binding variable.For example, the tool 124 can create an I/O binding variable in responseto receiving a request with variable name to add a new variable. Moreparticularly, the user can input a variable name in the IO binding pageof the RTU configuration workspace, and then the new I/O variable willbe created in IEC programming workspace automatically As anotherexample, the tool 124 could receive a name of an I/O binding variablefrom custom text input to a field in the Name column 320 a, such as whena user types or pastes a custom name into the Name column 320 a for avariable. In block 510, the tool 124 receives a type of the I/O bindingvariable. The tool 124 could identify the type in any suitable manner,such as based on the section of a table in which the I/O bindingvariable is being identified.

In block 515, the tool 124 receives a selection to compile a project.For example, the selection to compile can be a selection to “make” aproject or a selection to “rebuild” a project. In block 520, the tool124 automatically assigns an IEC address to an I/O binding variable. Forexample, the tool 124 can automatically assign an IEC address to eachI/O binding variable without an IEC address. In this embodiment, thetool 124 automatically assigns an IEC address to an I/O binding variablein response to receiving the selection to compile, although this couldbe done in response to other actions.

Block 520 here includes blocks 525-550. In block 525, the tool 124determines a number of I/O binding variables without an IEC addressassigned to the variable(s). In block 530, the tool 124 determines thetype of each I/O binding variable, which could be done for all bindingvariables or only those lacking an IEC address. In block 535, the tool124 determines the size of each I/O binding variable, which again couldbe done for all binding variables or only those lacking an IEC address.The size of a binding variable can be based on the determined type forthat binding variable. In block 540, the tool 124 determines whether atleast one memory has a suitable free space for each I/O bindingvariable, which again could be done for all binding variables or onlythose lacking an IEC address. For instance, the tool 124 could check thememory blocks 400-401 for suitable free space, such as by checking thememory block 400 for space for input binding variables and by checkingthe memory block 401 for space for output binding variables. If so, theprocess 500 proceeds to block 550. If not, the process 500 proceeds toblock 555.

In block 550, the tool 124 assigns an IEC address of the free space toan I/O binding variable. For example, the tool 124 can reserve asub-block having the same number of memory locations 410 as the size ofthe I/O binding variable without an IEC address and assign the first IECaddress of the reserved sub-block to the I/O binding variable. Note thatthe process of assigning an IEC address can include using an IEC addressstandard syntax according to the determined type of I/O bindingvariable.

In block 555, the tool 124 indicates that the memory does not contain asuitable free space for the I/O binding variables. For example, the tool124 could generate a display screen of an HMI that provides a visualindicator of which I/O binding variable(s) could not be assigned an IECaddress due to memory constraints. The indicator of which I/O bindingvariable(s) could not be assigned an IEC address could be generated andoutput as a visual indicator, an audio indicator, or other forms fornotifying an operator.

In block 560, the tool 124 generates a compilation of relationshipinformation and provides the compilation to an RTU 102. For example, thetool 124 could generate a table of the names of the I/O bindingvariables and their corresponding IEC addresses (including addressesthat were automatically assigned). The compilation of relationshipinformation is not limited to a table format and could be any suitableformat to notify an RTU 102 of the links between I/O binding variablesand IEC addresses.

Although FIG. 5 illustrates one example of a process 500 of I/O bindingwith automatic IEC address generation in an RTU configuration, variouschanges may be made to FIG. 5. For example, while shown as a series ofsteps, various steps in each figure could overlap, occur in parallel,occur in a different order, or occur any number of times.

In some embodiments, various functions described above are implementedor supported by a computer program that is formed from computer readableprogram code and that is embodied in a computer readable medium. Thephrase “computer readable program code” includes any type of computercode, including source code, object code, and executable code. Thephrase “computer readable medium” includes any type of medium capable ofbeing accessed by a computer, such as read only memory (ROM), randomaccess memory (RAM), a hard disk drive, a compact disc (CD), a digitalvideo disc (DVD), or any other type of memory. A “non-transitory”computer readable medium excludes wired, wireless, optical, or othercommunication links that transport transitory electrical or othersignals. A non-transitory computer readable medium includes media wheredata can be permanently stored and media where data can be stored andlater overwritten, such as a rewritable optical disc or an erasablememory device.

It may be advantageous to set forth definitions of certain words andphrases used throughout this patent document. The terms “application”and “program” refer to one or more computer programs, softwarecomponents, sets of instructions, procedures, functions, objects,classes, instances, related data, or a portion thereof adapted forimplementation in a suitable computer code (including source code,object code, or executable code). The terms “include” and “comprise,” aswell as derivatives thereof, mean inclusion without limitation. The term“or” is inclusive, meaning and/or. The phrase “associated with,” as wellas derivatives thereof, may mean to include, be included within,interconnect with, contain, be contained within, connect to or with,couple to or with, be communicable with, cooperate with, interleave,juxtapose, be proximate to, be bound to or with, have, have a propertyof, have a relationship to or with, or the like. The phrase “at leastone of,” when used with a list of items, means that differentcombinations of one or more of the listed items may be used, and onlyone item in the list may be needed. For example, “at least one of: A, B,and C” includes any of the following combinations: A, B, C, A and B, Aand C, B and C, and A and B and C.

The description in the present application should not be read asimplying that any particular element, step, or function is an essentialor critical element which must be included in the claim scope: the scopeof patented subject matter is defined only by the allowed claims.Moreover, none of these claims are intended to invoke 35 USC § 112(f)with respect to any of the appended claims or claim elements unless theexact words “means for” or “step for” are explicitly used in theparticular claim, followed by a participle phrase identifying afunction. Use of terms such as (but not limited to) “mechanism,”“module,” “device,” “unit,” “component,” “element,” “member,”“apparatus,” “machine,” “system,” “processor,” or “controller” within aclaim is understood and intended to refer to structures known to thoseskilled in the relevant art, as further modified or enhanced by thefeatures of the claims themselves, and is not intended to invoke 35U.S.C. § 112(f).

While this disclosure has described certain embodiments and generallyassociated methods, alterations and permutations of these embodimentsand methods will be apparent to those skilled in the art. Accordingly,the above description of example embodiments does not define orconstrain this disclosure. Other changes, substitutions, and alterationsare also possible without departing from the spirit and scope of thisdisclosure, as defined by the following claims.

What is claimed is:
 1. A method comprising: identifying, by at least oneprocesesor, that an input/output (I/O) binding variable for a remoteterminal unit (RTU) does not have an assigned InternationalElectromechanical Commission (IEC) address; and automatically assigning,by the at least one processor, an IEC address to the I/O bindingvariable by: identifying a type of the I/O binding variable; identifyinga size of the I/O binding variable based on the identified type, thesize representing a number of memory locations to be used to store theI/O binding variable in at least one memory of the RTU; and in responseto determining that the at least one memory contains a free space tostore the I/O binding variable based on the identified size, assigningthe IEC address identifying the free space to the I/O binding variable.2. The method of claim 1, further comprising: generating a compilationof relationship information that links the IEC address to the I/Obinding variable; and transmitting the compilation of relationshipinformation to the RTU.
 3. The method of claim 1, wherein: the methodfurther comprises receiving a selection to compile a project; andautomatically assigning the IEC address to the I/O binding variablecomprises automatically assigning the IEC address to the I/O bindingvariable in response to receiving the selection to compile the project.4. The method of claim 1, further comprising: identifying a name of theI/O binding variable.
 5. The method of claim 4, further comprising oneof: receiving the name of the I/O binding variable from a user; andgenerating the name of the I/O binding variable.
 6. The method of claim1, wherein the I/O binding variable comprises one of a plurality of I/Obinding variables.
 7. The method of claim 1, further comprising: inresponse to determining that the at least one memory does not contain afree space to store a second I/O binding variable based on an identifiedsize of the second I/O binding variable, generating and outputting anindicator identifying that the second I/O binding variable could not beassigned an IEC address.
 8. An apparatus comprising: at least oneprocessor configured to automatically assign an InternationalElectromechanical Commission (IEC) address to an input/output (I/O)binding variable for a remote terminal unit (RTU); wherein the at leastone processor is configured to: identify that the I/O binding variabledoes not have an assigned IEC address; identify a type of the I/Obinding variable; identify a size of the I/O binding variable based onthe identified type, the size representing a number of memory locationsto be used to store the I/O binding variable in at least one memory ofthe RTU; and in response to determining that the at least one memorycontains a free space to store the I/O binding variable based on theidentified size, assign the IEC address identifying the free space tothe I/O binding variable.
 9. The apparatus of claim 8, wherein the atleast one processor is further configured to: generate a compilation ofrelationship information that links the IEC address to the I/O bindingvariable; and initiate transmission of the compilation of relationshipinformation to the RTU.
 10. The apparatus of claim 8, wherein: the atleast one processor is further configured to receive a selection tocompile a project; and the at least one processor is configured toautomatically assign the IEC address to the I/O binding variable inresponse to receiving the selection to compile the project.
 11. Theapparatus of claim 8, wherein the at least one processor is furtherconfigured to identify a name of the I/O binding variable.
 12. Theapparatus of claim 11, wherein the at least one processor is configuredto one of: receive the name of the I/O binding variable from a user; andgenerate the name of the I/O binding variable.
 13. The apparatus ofclaim 8, wherein the I/O binding variable comprises one of a pluralityof I/O binding variables.
 14. The apparatus of claim 8, wherein the atleast one processor is further configured, in response to determiningthat the at least one memory does not contain a free space to store asecond I/O binding variable based on an identified size of the secondI/O binding variable, to generate and output an indicator identifyingthat the second I/O binding variable could not be assigned an IECaddress.
 15. A non-transitory computer readable medium embodyingcomputer readable program code that, when executed by at least oneprocessor, causes the at least one processor to: identify that aninput/output (I/O) binding variable for a remote terminal unit (RTU)does not have an assigned International Electromechanical Commission(IEC) address; and automatically assign an IEC address to the I/Obinding variable by: identifying a type of the I/O binding variable;identifying a size of the I/O binding variable based on the identifiedtype, the size representing a number of memory locations to be used tostore the I/O binding variable in at least one memory of the RTU; and inresponse to determining that the at least one memory contains a freespace to store the I/O binding variable based on the identified size,assigning the IEC address identifying the free space to the I/O bindingvariable.
 16. The non-transitory computer readable medium of claim 15,wherein the computer readable program code, when executed by the atleast one processor, further causes the at least one processor to:generate a compilation of relationship information that links the IECaddress to the I/O binding variable; and transmit the compilation ofrelationship information to the RTU.
 17. The non-transitory computerreadable medium of claim 15, wherein the computer readable program code,when executed by the at least one processor, further causes the at leastone processor to: receive a selection to compile a project; andautomatically assign the IEC address to the I/O binding variable inresponse to receiving the selection to compile the project.
 18. Thenon-transitory computer readable medium of claim 15, wherein thecomputer readable program code, when executed by the at least oneprocessor, further causes the at least one processor to: identify a nameof the I/O binding variable.
 19. The non-transitory computer readablemedium of claim 18, wherein the computer readable program code, whenexecuted by the at least one processor, further causes the at least oneprocessor to one of: receive the name of the I/O binding variable from auser; and generate the name of the I/O binding variable.
 20. Thenon-transitory computer readable medium of claim 15, wherein the I/Obinding variable comprises one of a plurality of I/O binding variables.